Software Defined Networking (SDN) in general, and OpenFlow in particular, describe a system where a controller installs packet processing rules into a forwarding element (e.g., a software or hardware switch). In all but the simplest examples, the rules form a packet processing pipeline, a series of matches and actions that determines the fate of a packet being processed. Consistency—making sure each packet is processed by a consistent set of rules, rather than a mixture of old and new rules—has been a long standing problem in the field. This problem was addressed in the OpenFlow specification version 1.4, that specifies the control signaling for “bundles”, or OpenFlow transactions. OpenFlow bundles have an optional “atomic” flag, that instructs the switch to commit the flow modifications of the bundle so that no packet being processed is handled by a mixture of old rules (ones being removed or modified by the flow modifications in the bundle) and new rules (ones being added or modified by the flow modifications in the bundle). The support for this “atomic” flag is optional to implement in the switch. The reason for this is that providing datapath atomicity without performance degradation is a hard problem to solve.
Implementing atomic flow table transactions is significant in the sense that with it we can provide hard security guarantees that would otherwise be only probabilistic in nature. Specifically, in all existing OVS-based system releases there exists a small window of inconsistency between the start and end of a set of flow table modifications issued by the controller. It is possible to further minimize the effect of the inconsistency by carefully crafting the order in which the modifications are performed, but in the general case such inconsistency can not be completely removed by such techniques.